Appl. No. 10/500,954 

Amdt. dated September 4, 2009 

Reply to Office Action of June 4, 2009 



REMARKS 

Claims 1, 2, 5, 6, 7, 8, 11, 12, 13, 14, 15, and 16 were 
pending in the Application at the time of examination. The 
Examiner rejected Claims 1, 2, 5, 6, 7, 8, 11, 12, 13, 14, 15, 
and 16 under 35 U.S.C. 103(a) as obvious over the Teblyashkin 
reference (EP 1291749) in view of the Cowie et al. reference 
(GB2378015) . 

Claims 1, 2, 5, 6, 7, 8, 11, 12, 13, 14, 15, and 16 remain 
in the Application. 



REQUEST FOR EXAMINER INTERVIEW 

The present Application was only recently transferred to 
Applicant's current Attorney. Consequently, Applicant's 
current Attorney has not been a party to the rather extensive 
file wrapper in this case. Applicant's current Attorney has 
reviewed the entire file available to him, however. Applicant's 
current attorney asks that, as a professional courtesy, should 
the Examiner be of the opinion that this Amendment does not 
place the Application in a condition for allowance, the 
Examiner grant an Examiner Interview prior to the issuance of 
the next communication from the USPTO. Applicant's Attorney 
can reached at telephone no. (831) 642-9980 

REJECTION OF CLAIMS 1, 2, 5, 6, 7, 8, 11, 12, 13, 14, 15, 
and 16 UNDER 35 U.S.C. 103(a) 

The Examiner rejected Claims 1, 2, 5, 6, 7, 8, 11, 12, 13, 
14, 15, and 16 under 35 U.S.C. 103(a) as obvious over the 
Teblyashkin reference (EP 1291749) in view of the Cowie et al. 
reference (GB2378015) . 
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Applicant's independent Claim 1 reads as follows, with 
emphasis added: 

An anti-malware file scanning system for computer files 
being transferred between computers, the system being 
implemented on a computer apparatus and comprising: 

a) a computer database containing records of known 
executable programs which are deemed to be not malware and 
criteria by which a file being processed can be determined to 
be an instance of one of those programs, the criteria including 
at least one characteristic signature associated with each said 
instance; 

b) means for processing a file being transferred between 
computers, the means b) comprising: 

a file recogniser operative to determine whether the 
file being processed is an instance of a known program by 
checking the contents of the file being processed for the 
presence of said at least one characteristic signature 
associated with the said instances; and 

a difference checker operative, in the case that the 
file recogniser determines the file being processed to be 
an instance of a known program, to check whether the file 
is an unchanged version of that known program; and 

c) means for signalling the file, depending on the 
determination made by the processing means, as being; 

likely to be not malware if it is an unchanged 
version of a known file; 

likely to be malware if it is a changed version of a 
known file; or 

of unknown status if it is not determined as being an 
instance of a known file. 
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Applicant's independent Claim 7 reads as follows, with 
emphasis added: 

A method of anti-malware scanning computer files being 
transferred between computers, the method comprising: 

maintaining a computer database containing records of 
known executable programs which are deemed to be uninfected and 
criteria by which a file being processed can be determined to 
be an instance of one of those programs, the criteria including 
at least one characteristic signature associated with each said 
instance; 

processing a file being transferred between computers by 
determining whether the file being processed is an 
instance of a known program by checking the contents of the 
file being processed for the presence of said at least one 
characteristic signature associated with the said instances, 
and 

checking, in the case that the file is determined to be an 
instance of a known program, whether the file is an unchanged 
version of that known program; 

signalling the file, depending on the determination made 
by the processing, as being; 

likely to be not malware if it is an unchanged 
version of a known file; 

likely to be malware if it is a changed version of a 
known file; or 

of unknown status if it is not determined as being an 
instance of a known file; and 

storing the determination that the file is likely to be 
not malware, is likely to be malware or is of unknown status. 
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Applicant's independent Claim 13 reads as follows, with 
emphasis added: 

An anti-malware file scanning system for computer files 
being transferred between computers, the system comprising: 

a computer database containing records of known executable 
programs which are deemed to be not malware and criteria by 
which a file being processed can be determined to be an 
instance of one of those programs, the criteria including at 
least one characteristic signature associated with each said 
instance; 

a processor for processing a file being transferred 
between computers, the processor being operative to determine 
whether the file being processed is an instance of a known 
program by checking the contents of the file being processed 
for the presence of said att least one characteristic signature 
associated with the said instances and, in the case that the 
file being processed is determined to be an instance of a known 
program, to check whether the file is an unchanged version of 
that known program, 

said processor, depending on the determination, 
identifying the file being processed as (i) likely to be not 
malware if it is an unchanged version of a known file; (ii) 
likely to be malware if it is a changed version of a known 
file; or (iii) of unknown status if it is not determined as 
being an instance of a known file. 



As seen above, each of Applicant's independent Claims 1, 7 
and 13 specifically recites signaling (Claims 1 and 7) or 
identifying (Claim 13) the file, depending on the determination 
made by processing, as being: likely to be not malware if it is 
an unchanged version of a known file ; likely to be malware if 
it is a changed version of a known file ; or 
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of unknown status if it is not determined as being an instance 
of a known file, or words to substantially identical effect. 

This feature of Applicant's Claims is discussed throughout 
Applicant's Specification. For instance, see page 2, line 31 
to page 3, line 30 of Applicant's Specification, as filed. 

In making the rejection of Applicant's independent Claims 
1, 7 and 13, the Examiner acknowledges that the Teblyashkin 
reference fails to disclose, teach, or suggest signaling 
(Claims 1 and 7) or identifying (Claim 13) the file, depending 
on the determination made by the processing, as being: likely 
to be not malware if it is an unchanged version of a known 
file ; likely to be malware if it is a changed version of a 
known file ; or of unknown status if it is not determined as 
being an instance of a known file. However, the Examiner then 
asserts that this recited feature is disclosed in Cowie at 
page 9, lines 6 to 22. In particular, the Examiner 
specifically asserts that Cowie teaches that it the file is an 
unchanged version, it is unlikely malware and is likely to be 
malware if it is a changed version of a known file at page 9, 
lines 6 to 22. 

Page 8, line 10 to page 10, line 10 of the Cowie 
reference, including the text cited by the Examiner, reads as 
follows : 

Fingerprint data characteristic of the resource data of 
FIG. 2 is generated for the purpose of rapid and robust 
identification of computer programs from their associated 
resource data. The fingerprint data can include variables such 
as the number of program resource items specified by the 
resource data and a time stamp value corresponding to the 
compilation time of the computer program concerned that is 
given within the resource specifying data at the start of that 
data in accordance with the known format. Another 
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characteristic of the resource data that tends to be highly 
individual to a computer program is the co-ordinate position of 
the resource item having the largest specified size within the 
hierarchy together with the size value of that resource data. 

A characteristic checksum value can also be calculated by 
parsing through the hierarchy. In particular, the checksum 
value can add in the number of resource items specified beneath 
each node within the hierarchy as the hierarchy is 
progressively traversed by tracking down each path to the 
lowest point within the hierarchy and then tracing back to the 
closest un-taken path and then tracking down that path. This 
parsing path is schematically illustrated by the dotted line in 
FIG. 2. 

As well as adding in the number of items to the checksum 
as described above, the checksum may also add in the ASC II 
values of any strings naming particular resource items that are 
encountered during this parsing. Furthermore, the size values 
encountered for each resource as specified at the bottom level 
within the hierarchy may be added into the checksum. 

FIG. 3 schematically illustrates the format of the 
checksum value. The checksum is generated whilst "walking" the 
resource tree structure, and is composed of the following 
elements in the resource section header . . . 

1) The total number of entries contained in each node of the 
tree 

2) The size of each individual resource item 

3) The ASCII string name of any resource item that has a name 
ID. 

These items are combined into the 64 bit checksum 
accumulator with a 32 bit XOR operation on the lower 32 bits of 
the checksum accumulator. After every XOR operation the 
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checksum accumulator is rotated 1 bit to the left in order to 
provide an order dependence to the checksum value. 

FIGS. 4a, 4b and 4c illustrate three different types of 
fingerprint values that may be employed. All three types of 
fingerprint are 16 bytes in length. The first byte is a control 
byte that indicates which type of elimination data is specified 
within that fingerprint. The next six bytes specify the 
elimination data. The following one byte specifies the number 
of entries processed in calculating the checksum. The final 
eight bytes specify the checksum itself. 

FIG. 4a illustrates the fingerprint format. 

FIG. 4b illustrates the control byte. Bits 4, 5 and 6 
comprise a 3-bit field specifying the elimination data type as 
being one of co-ordinate/size data, timestamp data or file 
length data. Bits 0, 1, 2, 3, and 7 are reserved. 

FIG. 4c illustrates the different elimination data formats 
for the three different types of fingerprint. Type 1 is the 
primary type of fingerprint employed. Type 1 fingerprints 
specify the number of entries within the hierarchical resource 
data, the co-ordinates of the largest resource, the size of the 
largest resource and the checksum value. The first three items 
in this fingerprint are indicative of the computer file 
concerned, but are not generally as highly specific as the 
checksum value. The main reason for the inclusion of the first 
three items within the fingerprint is to provide a mechanism 
for rapid elimination of fingerprints as non-matching when 
conducting a search through a large number of potential 
fingerprints. These three items of data may be used to hash 
into a large table of fingerprints to reduce the number of 
candidate fingerprints that need to be searched and thereby 
increase the processing speed. The checksum value tends to be 
highly specific to a particular collection of resource data and 
may be a 64-bit checksum number as discussed above or a 32-bit 
checksum number in less sophisticated systems. 
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Applicant respectfully submits that nothing in the text 
above, including the text cited by the Examiner, supports the 
Examiner's assertion that signaling (Claims 1 and 7) or 
identifying (Claim 13) the file, depending on the determination 
made by the processing, as being: likely to be not malware if 
it is an unchanged version of a known file ; likely to be 
malware if it is a changed version of a known file ; or of 
unknown status if it is not determined as being an instance of 
a known file is disclosed, taught, or suggested at Cowie at 
page 9, lines 6 to 22. Applicant respectfully submits that the 
text above does appear to describe a version of a checksum 
process, however, the checksum process is not disclosed as 
being performed for the purpose of signaling (Claims 1 and 7) 
or identifying (Claim 13) the file, depending on the 
determination made by the processing, as being: likely to be 
not malware if it is an unchanged version of a known file ; 
likely to be malware if it is a changed version of a known 
file; or of unknown status if it is not determined as being an 
instance of a known file. Indeed there is no mention of any 
processing for the purpose of identifying a changed version 
indicative of the presence of malware in the text above. 

In light of the discussion above. Applicant respectfully 
submits that the Examiner's assertion that signaling (Claims 1 
and 7) or identifying (Claim 13) the file, depending on the 
determination made by the processing, as being: likely to be 
not malware if it is an unchanged version of a known file ; 
likely to be malware if it is a changed version of a known 
file; or of unknown status if it is not determined as being an 
instance of a known file is disclosed, taught, or suggested at 
Cowie at page 9, lines 6 to 22 is not supported by the art of 
record. Consequently, Applicant respectfully requests the 
Examiner withdraw the rejection of Applicant's independent 
Claims 1, 7, and 13 and allow Claims 1, 7, and 13 to issue. 
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In addition: Claims 2, 5 and 6 depend on Claim 1 and 
therefore include all of the features and limitations of 
Claim 1; Claims 8, 11 and 12 depend on Claim 7 and therefore 
include all of the features and limitations of Claim 7; and 
Claims 14, 15, and 16 depend, directly or indirectly on 
Claim 13 and therefore include all of the features and 
limitations of Claim 13 . Consequently, Applicant respectfully 
requests the Examiner withdraw the rejection of Applicant's 
Claims 2, 5, 6, 8, 11, 12, 14, 15, and 16 and allow Claims 2, 
5, 6, 8, 11, 12, 14, 15, and 16 to issue for at least the 
reasons set forth above. 



For the foregoing reasons. Applicant respectfully requests 
allowance of all pending claims. If the Examiner has any 
questions relating to the above, the Examiner is respectfully 
requested to telephone the undersigned Attorney for Applicant. 



CONCLUSION 



CERTIFICATE OF TRANSMISSION 



Respectfully submitted. 



I hereby certify that this correspondence is being transmitted 
to the United States Patent and Trademarlc Office via the 
Office's EFS-Web system on the date shown below. 



/Philip McKay, Reg. No. 38,966/ 



September 4. 2009 
Date of Signature 



Philip McKay 

Attorney for Applicant (s) 
Tel.: (831) 655-0880 



Mona Marshall 
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